Modern communications networks are demanding heterogeneous environments having associated complex communication, management, and support requirements. Some components may act as servers under some circumstances and as clients under others, in a hierarchy of control and management functions, in addition to the primary mission of effecting communications. Certain components are relatively permanent in the network structure, yet others are intermittently part of the active network because they are mobile or remotely-operated. In addition, while many network components are “always on”, others may be made dormant during periods of inactivity or maintenance. In view of the above, it is desirable that advanced high-bandwidth, high-performance, local bus adapters and controllers operate robustly and intelligently in most, if not all, environments, thereby forcing designers to make trade-offs between features and functionality, and available motherboard slots or board real estate.
The term “system manageability” represents technologies that enable remote system access and control in both OS-present and OS-absent environments. “OS-absent” is defined herein as a networked computer system being in a state including, without limitation, no active OS, inoperable OS, or low-power, system-sleep state. These technologies are primarily focused on minimizing on-site maintenance; maximizing system availability and performance to the local user; maximizing remote visibility of (and access to) local systems by network administrators; and minimizing the system power consumption required to keep this remote connection intact. Technologies that require the OS to be present do not allow an administrator to have remote visibility or access to systems that have serious hardware or software problems, which prevent the OS from loading or working correctly. In addition, such OS-present technologies do not allow for a system to be remotely managed while in a low-power mode.
Furthermore, computer processors typically communicate with cooperating components along one or more computer buses. Peripheral components, including audio, and print devices, portable storage media, and low bandwidth networking devices usually are coupled with the bus through a peripheral or expansion computer bus interface adapter. On the other hand, devices with high bandwidth needs, including video, memory, high-performance networking, and core storage media often are linked to the CPU via a high bandwidth local bus interface adapter. Components on expansion buses typically have operational speeds many orders of magnitude slower than that of the CPU; however, such components sporadically access CPU and system resources and, thus, critical design issues such as bus latency, setup & hold times, and clock-to-data time are of little import to interface adapters designed for those applications.
Although high-bandwidth, high-performance, local bus components and adapters tend to operate at clock speeds much higher than their expansion bus counterparts, they still lag current CPU speeds by about an order of magnitude. However, because local bus components tend to interact with the CPU to a significant degree, slow, inefficient, and poorly-designed local bus interface adapters can potentially waste substantial amounts of processor and system resources. Therefore, local bus interface adapters are usually faced with observing strict timing budgets when accessing and providing data to the local bus.
Many factors can lead an adapter to violate the timing budget imposed by a bus protocol. For example, delays introduced in the clock trees and in the data paths of bus adapters, or both, can effectively decouple the interface adapter from the bus, because the adapter response time fails to remain synchronized to the bus clock. The functional characteristics of VLSI devices employed in such high-bandwidth, high-performance computer bus interface adapters can be susceptible to design and process variations during manufacturing. Also, the response of such adapters can be compromised by variations in environmental conditions while operating.
There is a need, then, for a local bus interface adapter that mitigates critical path delays within a computer bus interface adapter, or device, to the extent that they do not violate the aforementioned timing budgets. It is desirable that such an adapter is robust to design and process variations during manufacturing, as well as to the environmental conditions, which may be encountered during operations. Because multiple local bus protocols exist in common computer environments, there also is a need for a robust, multiprotocol computer bus interface adapter that is observant of stringent bus protocol timing budgets. There also is a need for an advanced, high-performance, high-bandwidth local bus adapter/controller that integrates complex network communication, management, and support features and functions onto a single VLSI chip.
To reduce the total cost of ownership of computing systems such as personal computers, a number of technologies have been developed to provide more cost effective system maintenance and to maximize system “up-time”. For example, some of these technologies give IT administrators more visibility and control over remote systems. Traditionally, these technologies require that the “managed” system is an operational state with the Operating System (e.g., Microsoft Windows®) of the computing system loaded.
Examples of technologies that require the operating system (“OS”) to be loaded are DMI and CIM.
In general, however, technologies that require the OS to be loaded do not allow an administrator to have remote visibility or access to systems that have serious hardware or software problems that prevent the OS from loading or working correctly. In addition, these technologies do not allow for a system to be remotely managed while in a low power mode. For these scenarios, there is a need for a standardized low-level technology that gives administrators remote access to and control over the managed system.
Several vendors have developed proprietary technologies in this area. Intel and IBM created Alert on LAN (AoL) technology. AoL provided remote notification of local system states and various hardware or software failures in an OS absent environment. In addition, Intel and others developed the Platform Event Trap (“PET”) format, to describe how alerts were formatted over the network.
As the number of these technologies increased, computing system vendors were faced with the possibility of having to support several different alerting standards. As a result, the Distributed Management Task Force developed an open remote control and alerting standard: the Alert Standard Format (“ASF”).
ASF is a specification that defines methods for alerting and remote system control. ASF is specifically targeted at OS-absent environments. As used herein, the term “OS-absent” refers to a computer system that is in a state including, without limitation, a no active OS state, an inoperable OS state, a low-power state, and/or a system-sleep state.
The remote control and alerting system defined by ASF includes a management system that communicates with one or more clients. Here, the term “client” refers to a managed computing system. Typically, the management system is located remotely from the computing systems and communicates with the clients via a network. An alert sending device (“ASD”), which is a component in each client, interfaces with other components in the computing system to respond to remote control requests from the management system. Such requests include, for example, power-up, power-down and maintenance requests. The ASD also interfaces with sensors in the client computing system. When a sensor detects an “alert event,” the ASD in the client sends a corresponding alerting message to the management system. To this end, the ASF specification defines interfaces for sensors, alert sending devices (which may include, for example, network interface cards or Modems), remote management console software, and system firmware in order to allow system vendors (and system component vendors) to develop ASF compliant products.
In summary, the above technologies, collectively referred to as “system manageability” technologies, enable remote system access and control in both OS-present and OS-absent environments. These technologies are primarily focused on minimizing on-site maintenance; maximizing system availability and performance to the local user; maximizing remote visibility of (and access to) local systems by network administrators; and minimizing the system power consumption required to keep this remote connection intact.
While the technologies discussed above address some of the problems associated with “system manageability,” they fall short of addressing many issues involved in providing a robust remote control and alerting system for computing systems. In particular, in networked computing systems, there is a need for a cost effective, yet highly high functional system for managing a computing system using standard protocols when the OS is not present.